Historique linéaire via le fast-forward n'est possible que lorsque l'historique des branches forme une ligne droite de descendants. Dès que la branche principale et la branche fonctionnalité se séparent, le simple « déplacement du pointeur » d'un merge en fast-forward devient mathématiquement impossible.

1. La distinction concrète

Les fusion en fast-forward ne sont pas réfléchies dans l'historique du projet. Cela signifie que l'existence unique de la branche est effectivement effacée lors de son intégration. En revanche, les fusion en trois voies préservent le récit du travail parallèle.

2. Le principe de l'historien

La branche principale master agit comme l'historien de tout notre projet. Elle ne peut enregistrer que ce que nous lui permettons de voir ; lorsque les chemins se séparent, nous sommes obligés de créer un nouvel « événement » — un commit de fusion — pour combler le fossé et reconcilier deux réalités différentes qui ont évolué simultanément. commit de fusion—to bridge the gap and reconcile two different realities that evolved simultaneously.

3. Détection de la divergence

En utilisant git log --oneline, les développeurs peuvent visualiser où les chemins se séparent. Si « master » a avancé depuis que vous avez créé votre branche, Git ne peut pas déplacer le pointeur en avant sans perdre le nouveau travail sur master.